Some questions about this.

Why are the files in a seperate src directory?

Why a separete makefile?

Why is there an hp3k_defs.h file in the RTX2001 simulator?

Hello Richard!

Why are the files in a seperate src directory?

Files are in src/ as there is a corresponding test/ directory that isn't part of the PR. It turns out any Rust advantage would've been strictly in the language UX. Reliant as I am on TDD, I found it impossible to make any progress w/o employing that technique for this project. I wound up adopting the Unity framework. It seems such C testing frameworks still require they supply main(). There can only be one MCP, a requirement which means test/ contains sim_stub.c, i.e., sim.c stripped of main(). Assuming that would be a "bridge too far", I've decided that test/ is more a "booster stage into orbit", test/ will not make it to github. It's on gitlab in case it's needed, but I don't think it should be in the PR.
I'll move the files to rtx2001a/ as part of that orbital burn manoever.

Why a separete makefile?

Believe it or not, I didn't discover the listserv until I was ready to create this PR. If I'd asked, I'm sure there wouldn't be a separate file.
I'll integrate it into simh/makefile

Why is there an hp3k_defs.h file in the RTX2001 simulator?

It's a core set of definitions, as such lifted directly from that project. I didn't want to lose the provenance, and I'm not sure how to require files from another project. I'll ask on the listserv and make the appropriate changes.

@jchimene: There are preliminary hooks in the CMake infrastructure to support Unity-based tests, which would be a future merge request. So, don't throw them away, yet. (Part of my background is in space systems, where TDD is critically important.)

HEAD now reflects the requests:
o Integrated makefile
o Discard hp3k_defs.h
o Discard src/

It's still alpha level

If the project is interested in this PR, please let me know. There's still a fair amount of debugging to get this thing operational.

There is still a symlink to sim_defs.h which will not work on Windows. Also why is there one header file in the src directory?

It should build cleanly on at least Linux, not only macOS. I've explained in private email the issue.

If the project is interested in this PR, please let me know. There's still a fair amount of debugging to get this thing operational.

There is still a symlink to sim_defs.h which will not work on Windows. Also why is there one header file in the src directory?

I'm not seeing src/ in my version. How are you seeing that on https://github.com/jchimene/openSimh/tree/rtx2001a/RTX2001A? The sim_defs.h file should be gone from the repo.

It should build cleanly on at least Linux, not only macOS. I've explained in private email the issue.

I'm not sure what the issue is on Linux. The makefile is pretty vanilla right now.
I can't help Windows; such work is a show-stopper.

Beyond and related to the "issue on Linux", you can try to build your simulator on your macOS platform, but using a different compiler (we look for as many different compilers to examine the code for compatibility issues)., If you build with:

$ make rtx2001a GCC=clang++

You'll see the category of issues Linux and other platforms will have. I pointed out the details to you in a private message, and you've chosen to ignore that input.

I'll state this again:

You SHOULDN'T declare global variables in include files, especially in include files which are included in many places.
You SHOULD declare such variables as 'extern' (if necessary) in include files and explicitly declare them globally where they belong.

If you follow this advice the build will work better in more places.

@markpizz
I'm not ignoring your feedback. Multi-platform builds are not important enough to address right now. My current concern is gettng to a MVP. Multiple platform considerations are secondary.

I'm not ignoring your feedback. Multi-platform builds are not important enough to address right now. My current concern is gettng to a MVP. Multiple platform considerations are secondary.

Expecting continued feedback on this PR after useful information has already been provided without being adopted is asking for a lot.

Most folks here would presume that if you are presenting a Pull Request (PR), then you think it is close to be ready to be merged. Feedback about the barriers to merging, and the solutions to those barriers is what you'll be getting.

I'm glad you've brought up the kbhit() subject on the simh list. That could be discussed here as well since you've exposed the code that uses it.

Your simulator code should avoid using OS provided API's and OS provided include files. Include sim_defs.h and other sim_xxx.h files and use the APIs they provide. If you think you need something else, feel free to ask here or on the simh list.

I can build this (tried it on a Mac, including building as universal just for fun) and it starts ok. Not sure what I can do after that point. This is a FORTH machine, right? It's a bit puzzling to see an emulated computer that only has a CPU, no I/O devices.
Is there any code that can be loaded into this? I tried "run" to see if that would give me a FORTH interpreter prompt, but it just hits a bad opcode. Tried "boot" but that complains I didn't give it a device name. Hard to do that without devices...

@pkoning2
/me shuffles feet
The best you'll get is the opening copyright. It's not handling the console correctly.

The purpose of this PR was to start a discussion of whether or not this simulator is interesting for simh.

After building
./BIN/rtx2001a rtx2001a/simh.ini

which is not on github as it's still in development

# use for rtx2001a
# set log -n /tmp/rtx2001a.log
# set debug -PF /tmp/rtx2001a.log
set nolog
set debug -f stdout
# set CPU NODEBUG=CPU;MEBR;MEBW;ASBR;ASBW;PSBR;PSBW;RSBR;RSBW
if exist "%SIM_BIN_NAME%/rom.ini" do "%SIM_BIN_NAME%/rom.ini"
if exist "rom.ini" do "rom.ini"
# set break -s -p
# set CPU DEBUG=CPU;MEBR;MEBW;ASBR;ASBW;PSBR;PSBW;RSBR;RSBW
# set CPU deb=CPU;ASBR;ASBW;
#
# boot routine
#
dep ir 0x175D
dep pc 2
#
# verify boot state
#
ex state
set on

after the above, issue the "go" command. You'll get the Harris copyright statement and then the bitbucket.

This is a FORTH machine, right?

Yes

It's a bit puzzling to see an emulated computer that only has a CPU, no I/O devices.
Agreed. It does have a console, but nothing else.

It's purpose is to see if the simh design will provide the infrastructure to simulate a Forth machine, specifically the Novix processor with its single cycle instructions and zero-cycle return instructions. Since technical Novix documentation doesn't seem to be openly available, I selected the RTX2000 family, specifically the RTX2001A, which adds Harris' Quadbus design and ASIC library implementation.

That it's an embedded controller does pose some challenges for this project. As you've noticed, there isn't much in the way of external devices. The only answer I can give now is that primitive DOS operations will be via the simh filesystem; the console, as you've seen, will be via the simh console. Should requirements for ASIC bus connections arrive, those would be accomplished via the simh UNIT subsystem.

Thanks. My reaction is that yes, this seems like a fine thing to add to SIMH. It would be good to include a document for the "doc" directory that describes what this is, how to operate it, and (if relevant) where to find bits that can run on it.
A machine that just has a CPU and console is ok, there are some other emulators that don't have a whole lot more than that.

Hm, I tried that INI file and "go" and got a bunch of debug messages followed by an invalid opcode error. No copyright message.

Hm, I tried that INI file and "go" and got a bunch of debug messages followed by an invalid opcode error. No copyright message.

The github version needs a refresh. I've been avoiding a push until the Forth inner interpreter is on the air.

Thanks. My reaction is that yes, this seems like a fine thing to add to SIMH. It would be good to include a document for the "doc" directory that describes what this is, how to operate it, and (if relevant) where to find bits that can run on it. A machine that just has a CPU and console is ok, there are some other emulators that don't have a whole lot more than that.

Great! Thanks for taking this on. I appreciate the company.

I've been an (occasional) FORTH user since the 1980s (I created the FORTH runtime system (somewhat extended FIG-FORTH) that's included with recent RSTS/E releases, and wrote a 4000 line tool with that. I've also looked a bit at various FORTH FPGA designs, so a FORTH processor emulation feels natural.

I've been an (occasional) FORTH user since the 1980s (I created the FORTH runtime system (somewhat extended FIG-FORTH) that's included with recent RSTS/E releases, and wrote a 4000 line tool with that.

It's an ineresting language. I admit I don't have much use for it day to day. I haven't seen RSTS/E since 1983. Forth and RSTS/E with its runtime system support certainly makes sense.

I've also looked a bit at various FORTH FPGA designs, so a FORTH processor emulation feels natural.

Good. It represents a design that's not found in other of the simulators.

My pupose with simh is to illustrate the multi-issue quadbus.

Here's an interesting image:

The single-cycle return and multi-issue data fetch can be logged. I've gotten to the "yep, there it is" goal via the simh debug macros. At some point, I'll devise some external bus signal visualizer.

All of which assumes I can get the thing on the air. It also assumes a usable APPFORTH image. I have a growing suspicion that APPFORTH is the bootstrap that gets to usable dictionary.

Hm, I tried that INI file and "go" and got a bunch of debug messages followed by an invalid opcode error. No copyright message.

The github version needs a refresh. I've been avoiding a push until the Forth inner interpreter is on the air.

@pkoning2 : It should build now.

To start:
./BIN/rtx2001a rtx2001a/simh.ini

issue the GO command, then hit <CR> after the credits.
You should get an "Ok" prompt. Then kill the image.

Please flag non-compliance. To do that, please comment out line 7 of simh.ini to enable logging and post the last few steps to the crash.

• get to BYE
• Documentation
• ?

This version now handles the keyboard correctly, and can exit at the BYE command

To start:
./BIN/rtx2001a rtx2001a/rtx2001a.ini

then type GO, press to get an OK prompt, type BYE

Not much else works right now.

There is a start of documentation for this simulator.

What other work is needed before approving this PR?

This gets my gall. You're telling me that you'll give the the Sooper Sekret Formula if it's for your sandbox?
That you could even feel free to make this statement in public tells me much about the state of this project.

The super secret formula have all been expressed again here. There are no secrets about this. Some folks prefer to work out the problem details at home rather than in the middle of the street.

It's not adversarial. I don't respond according to your timeline.

The timeline you respond with is completely yours, but ultimately all the issues that have been raised need to be addressed. You are the one who specifically asked (#157 (comment)):

What other work is needed before approving this PR?

Then you say:

Compilation on Windows is a dealbreaker.

You get to pick and choose the order you address the issues, but you don't get to only pick the issues you care about and expect the PR to be done!

On 1/30/23 07:43, Mark Pizzolato wrote:

This gets my gall. You're telling me that you'll give the the Sooper Sekret Formula if it's for your sandbox?
That you could even feel free to make this statement in public tells me much about the state of this project.

The super secret formula have all been expressed again here. There are no secrets about this. Some folks prefer to work out the problem details at home rather than in the middle of the street.

I still don't see an answer. I see a problem report.

I've also seen a problem report from @pkoning2 , but no followup.

I've discussed comments with @rcornwell It's not like I don't know how to write comments for source code control. Writing comments in that style was my choice, intended to provoke a discussion. I think comments should describe why something was done, not what was done.

It's not adversarial. I don't respond according to your timeline.

The timeline you respond with is completely yours, but ultimately all the issues that have been raised need to be addressed. You are the one who specifically asked (#157 (comment)):

What other work is needed before approving this PR?

Then you say:

Compilation on Windows is a dealbreaker.

You get to pick and choose the order you address the issues, but you don't get to only pick the issues you care about and expect the PR to be done!

True. That's why I've closed the PR and deleted the fork. Considering Paul and Richard's comments about building on Windows, less concrete suggestions; requiring a build using three compilers on MacOS; some line-ending issue in the makefile; all illustrate that this is not the project for me. I know when a project is forcing a newb to jump through hoops.

You get to pick and choose the order you address the issues, but you don't get to only pick the issues you care about and expect the PR to be done!

True. That's why I've closed the PR and deleted the fork. Considering Paul and Richard's comments about building on Windows, less concrete suggestions; requiring a build using three compilers on MacOS; some line-ending issue in the makefile; all illustrate that this is not the project for me.
I know when a project is forcing a newb to jump through hoops.

All newb's jump through the same hoops and then happily move on.

It's your choice to move out instead. Good Luck.

I'm sorry I haven't had a chance to try your latest fixes -- day job gets in the way sometimes...
As for the log comments, I'm not sure why it would be reasonable to write those in a style entirely different from the convention set by the project. Having worked on a bunch of open source projects, I know that the rules may vary from one to the next, and they might be fairly loose or not so much, but there always is an expected style and contributions that don't follow these will get pushback. That's true for GCC; it's true for SIMH. I can't see why that is an unreasonable hoop.
On the three compilers, I'm not sure why that should be required. I would think the default (llvm, a.k.a., clang, typically masquerading as "gcc") on MacOS should be sufficient. But of course on Linux you'd be using GCC and on Windows MSVC, so you're dealing with the need to write portable code no matter what.

This seemed like an interesting simulator. It's unfortunate you changed your mind about wanting to contribute it. Perhaps in the future...

Yes, it would be useful to have a "how to contribute" document. There is simh.doc, but that doesn't answer all the questions, obviously.
As for clang++, since SIMH is written in C I'd say that it is not relevant. If SIMH compiles correctly with C compilers for the major platforms, that's good.
You're right that currently getting MS building added is not so easy. One reason I like the CMake effort -- which hopefully should get merged at some point soon -- is that it addresses this, allowing a simulator to be built on Windows without required Windows expertise on the part of the contributor. At least that's the intent; it will be interesting to test this notion against a new simulator.

Yes you do know how to write a comment. However without identifying the simulator the comment refers to how am I to determine which commits are important or not to my bug. With simulator name in first line of commit comment I can tell exactly which simulator this commit refers to. With a description of the change in the first line I can also tell whether this could be related to the bug I am trying to track down. Commit comments are not about provoking discussion they are about identifying to those who come along later what was changed. You are free to add in your provocative part of the commit on other lines of the commit other then the first two.

@rcornwell Discussion is why I opened this PR in the first place. That's why I contribute to Open Source, and why I gravitated to this simulator in the first place. The Forth language is nothing without its freedom of expression. As I observed earlier, each practitioner brings their own CASE statement and disassembler. The Forth community is one whose email signatures range from the commercial to the curmudgeonly. That I took advantage of the PR, to make such provocative statements I claim ownership. Would that at least one here recognized the provenance of those lines w/o search engine amplification, how they obtain here.
You can squash commit such messages

This update attempts to address the VC code and line feed endings issues. Have at it!

Hello @jchimene , it looks like you reopened this PR, but pushed your changes to the master branch of your fork, instead of the rtx2001a branch. If you want to continue this PR, you can create a new rtx2001a branch in your repo and force push it.

That being said, I did download the code from your fork, and was able to build and run the RTX2001A using both Visual C++ 2008 and Visual Studio 2022, running on Windows 10.

sim> g

AppForth  v1.1b 7/31/90  13:30

COPYRIGHT 1990 HARRIS CORPORATION
ALL RIGHTS RESERVED

This software is provided by Harris Corporation, Semiconductor Sector
as a courtesy to its customers free of charge.  The programs and other
contents of the disk are not released products, and therefore are not
supported by Harris Corporation and no warranty of any kind applies.
Any liability resulting from use of this software is specifically
disclaimed by Harris Corporation.

61) bye
Goodbye, PC: 0752 (0xA0)
%SIM-INFO: Debug output disabled
PS C:\rtx2001a\rtx2001a>

Looks like this is getting close!

Take care,
Howard

@hharte Great to see! Mark threw some last minute changes over the transom, and it turns out I didn't do the makefile correctly w/r/t/ updates. I'll push a branch tomorrow.

On Sunday, February 5, 2023 at 4:21 PM, @markpizz wrote:

On Sunday, February 5, 2023 at 12:03 PM, Jeffrey Chimene wrote:

On 2/5/23 12:28, Mark Pizzolato - Info Comm wrote:

Jeff,

Attached files should replace what's in your current commit. With
these
changes, things build cleanly on Windows.

As I said in my original private message to you, the Windows
compiler is old
enough that variable declarations can't be just anywhere in the C
code, but must immediately follow a {. I moved each respective to the
closest enclosing {. You could alternatively put {} around the
section where you used these variables.

The doc file would go in the doc directory.

• Mark

Thanks - I'll add the sln file & move the doc file. The other changes
should also be there.

Jeff,

The simh.sln file AND the slightly modified rtx2001a.vcproj files go in the
"Visual Studio Projects" directory and replace those same files in that
directory.

While you're making minor changes, rtx2001a_cpu.c has:

#include "setjmp.h"

rather than

#include <setjmp.h>

Agreed

BTW, the changed simh.sln facilitates the CI/CD builds for windows. The
change to the rtx2001a.vcproj facilitates error free upgrades to newer
Windows Visual Studio compilers.

It seems that you were aware that for visual consistency reasons the simh project source code files shouldn't have
tabs. There is one stray tab in rtx2001a_cpu.c in this line:

• 3.8 Other Data Structures, simh.doc, pg 33

• Mark

I'm not responsible for simh.doc

Speaking of files I'm not responsible for: Would someone other than Mark please describe why I'm responsible for a file named "Simh.sln" for MSVC? Thanks.

It seems that you were aware that for visual consistency reasons the simh project source code files shouldn't have
tabs. There is one stray tab in rtx2001a_cpu.c in this line:

3.8 Other Data Structures, simh.doc, pg 33

I'm not responsible for simh.doc

Well, I never said you were responsible for the doc. What I did say was that you copied a line or two of text as comments from that simh.doc into your rtx2001a_cpu.c. In the middle of the copied lines there was a single tab. That tab should be replaced by a couple of spaces. No other tabs appear in your source code.

It seems that you were aware that for visual consistency reasons the simh project source code files shouldn't have
tabs. There is one stray tab in rtx2001a_cpu.c in this line:

3.8 Other Data Structures, simh.doc, pg 33

I'm not responsible for simh.doc

Well, I never said you were responsible for the doc. What I did say was that you copied a line or two of text as comments from that simh.doc into your rtx2001a_cpu.c. In the middle of the copied lines there was a single tab. That tab should be replaced by a couple of spaces. No other tabs appear in your source code.

Yes, I see what you're referring to.

Speaking of files I'm not responsible for: Would someone other than Mark please describe why I'm responsible for a file named "Simh.sln" for MSVC? Thanks.

You don't believe me? You're sounding adversarial again.

You are adding a new simulator and hence there needs to be build instructions for that to support Visual Studio builds. Those instructions involve

1. a .vcproj file which @hharte provided that had a minor extra few lines added automatically which interfere with folks who want to use a newer version of Microsoft Visual Studio. I removed those potentially interfering lines which otherwise have no effect on normal Windows builds.
2. adding one or more new projects (.vcproj files) needs to add the project being added to the list of all projects (the simh.sln file). Which also contains the build order. The file I sent you correctly implements this so that windows CI/CD builds using the projects do the right thing, and likewise for folks who actually build everything on Windows.

If you're providing one of these files for new simulators, you need to provide both.

In order to actually build on Windows, you need to be working with at least the .vcproj file. It seems that you just passed along the file that @hharte sent you without actually building since when I tried to build I needed to send you the various fixes that you subsequently added to the code. That IS NOT a problem. You don't have easy access to the Windows platform. If you're going to take the .vcproj file without testing, then you also need to take the updated simh.sln file.

Please ignore everything I've said above since it came from me and I know nothing about this stuff.

Speaking of files I'm not responsible for: Would someone other than Mark please describe why I'm responsible for a file named "Simh.sln" for MSVC? Thanks.

You don't believe me? You're sounding adversarial again.

That's just too bad. I eventually figured out the reason for the .sln after asking the above. I appreciate that you act as the project linter; which is why I take your code revisions seriously.
The .sln, no tabs, msdos line endings are all hoops through which newbs must jump; they are received knowledge.

Can PR this merge? If not, please provide a list of bullet points to check using github-flavored markdown. Please no private comments re: this PR.

I general, when a new simulator comes along or a very significant contribution, the contributors steps along the way would be squashed into one commit reflecting the general description of the contribution.

Apart from squashing, others (@pkoning2 specifically) have some personal experience with actually using a simulator like this. If they're happy then a merge is good with one additional detail: Please update your github profile to include your full name.

I sent you private messages to provide fixed/additional files which were easy as email attachments.

@jchimene I believe I told you all the things that you needed to do to be compatible with moving your source into the main open-simh tree. Such as no tabs, dos format files etc. Personally I agree 100% with the no tabs. They cause no end of trouble when the tab stops are not the same as the author. I personally have adopted this standard in all my projects. Except were required like in make files. Most of these items are quickly implemented and are not that burdensome. I also had to go through these hoops when I started submitting simulators.

One last thing which I've mentioned before.

Please update your local git configuration to also have your full name rather than the jchimene name. Look through the commits on the repo and you'll see that everyone goes by their whole name.

@jchimene I believe I told you all the things that you needed to do to be compatible with moving your source into the main open-simh tree. Such as no tabs, dos format files etc. Personally I agree 100% with the no tabs. They cause no end of trouble when the tab stops are not the same as the author. I personally have adopted this standard in all my projects. Except were required like in make files. Most of these items are quickly implemented and are not that burdensome. I also had to go through these hoops when I started submitting simulators.

I think we're there with the no tabs and dos format files. I can't see any other comments about those issues raised in #157 (comment)

Like, I said, Tabs and CRLF issues are good. My other points are still to be addressed.

Like, I said, Tabs and CRLF issues are good. My other points are still to be addressed.

The name thing I'm considering. I'm not sure I want my name associated in such a way. If ther are other issues, please put them in bullet poins.

I really enjoy repeating myself. Here you go:

• In general, when a new simulator comes along or a very significant contribution, the contributors steps along the way would be squashed into one commit reflecting the general description of the contribution.

• Apart from squashing, others (@pkoning2 specifically) have some personal experience with actually using a simulator like this. If they're happy and this list is addressed, then a merge is good.

• Please update your github profile to include your full name.

• Please update your local git configuration to also have your full name rather than the jchimene name in commits. Look through the commits on the repo and you'll see that everyone goes by their whole name.

As @rcornwell said, hoops are what everyone has gone through, once they're addressed, then they are behind you.

I just tried this, on Mac, with the rtx2001a.ini startup file. Entered "go" as instructed, nothing happens, no response to keyboard input.

Well, that's not encouraging.
I'm pretty sure you also have to execute step.simh
It also looks like the .doc file got mangled at some point.
The entire sequence should be
$ BIN/rtx2001a rtx2001a/rtx2001a.ini
simh> do rtx2001a/step.simh
.
.
.
simh> go

This is definitely an alpha-level tactic, although some of step.ini will be a test to run during a build

step.simh doesn't exist in the PR. And I noticed rtx2001a.ini tries to load appforth.hex which doesn't exist either. Missing files in the commit, perhaps?

I think something is not right with the way GitHub is handling this PR, possibly because the original rtx2001a branch was deleted. This PR still shows 7 (old) commits, while https://github.com/jchimene/openSimh shows only two.

@pkoning2 if you cherry pick the two commits from https://github.com/jchimene/openSimh, I think you’ll find the simulator is working.

I’m not sure how to fix this, but opening a new PR is one way.

ouch. sorry about that.